After the future removal of the classic playbook editor, your existing classic playbooks will continue to run, However, you will no longer be able to visualize or modify existing classic playbooks.
For details, see:
Use filters to separate artifacts before further processing with the classic playbook editor
Create conditions in a Filter block to separate a subset of artifacts. Only the artifacts matching the specified condition are passed along to downstream blocks for processing. This is useful when you want to remove artifacts that aren't needed in the flow of the playbook, or you need to separate artifacts because they require different blocks for processing. For example:
- If an IP address comes from North Korea or Turkey, you can block it.
- If an IP address comes from North America, you can perform an IP reputation lookup.
- If an IP address falls in the 192.168.10.* range, you can to grant access to the user.
Options in a filter aren't related to each other and you can perform multiple actions on an IP address. For example, both the second and third conditions in the example could be true, as an IP address in the 192.168.10.* range could both come from North America and be an internal user who was granted access. The filtered data set is given a named result in the format name="filter_1:condition_1"
and passed to the next block for processing.
Create a Filter block in your playbook
To create a Filter block, perform the following tasks:
- Create a new block in the classic playbook editor.
- Select Filter from the list of block types.
- Select the Select Parameter field and select the parameter you want to filter on. Parameters are made available to the Filter block by upstream blocks.
- Select the == field and select an operator for the filter.
- Select the Select Value field and select the value you want to match. See Example of creating a filter for an example of how these fields work together.
- (Optional) Select + to add parameters to this condition.
- (Optional) Select Add Condition to create another matching condition for the filter. You can have a maximum of five conditions per Filter block. Each condition has its own downstream path.
Example of creating a filter
In the following example, you can create a filter to perform a geolocate ip
action on a source IP address and block any IP addresses from North Korea. The following image shows the classic playbook editor in .
- Configure a
geolocate ip
action in the playbook editor. - Drag the half-circle icon on the
geolocate ip
action block in the editor. - Select Filter from the list of block types.
- Select the Select Parameter field and select geolocate_ip_1.
- Select geolocate_ip_1:action_result_data.*.country_name.
- Leave == as the operator, and type North Korea in the Select Value field.
Example of creating a filter with multiple conditions
You can create multiple rows within a condition or multiple conditions. The following image shows an example of the classic playbook editor in .
- Select Add Condition to create a second set of filter conditions, which also adds a second output point on the Filter block.
- In the Select Parameter field, select container properties and choose label.
- Select == as the operator, and enter Test in the Select Value field.
Multiple conditions within a filter block are independent of each other. The results of Condition 1 don't play into the set of inputs for Condition 2. In this example, Condition 1 uses the result from the geolocate ip
action, while Condition 2 uses a property of the container. Each condition has its own color to make it easier to identify the separate downstream actions. Green marks the path of Condition 1 and purple marks the path of Condition 2.
Example of filter chaining
You can also chain multiple filter blocks together to obtain a more specific set of data. The following image shows a chain of filters in the classic playbook editor.
For example, to filter out RFC1918 addresses (10.x.x.x, 172.16.x.x-172.31.x.x, and 192.168.x.x) and perform a geolocate ip
action on the remaining addresses, perform the following steps:
- From the Start block, create a new filter block.
- In the Select Parameter field, select event > src_ip.
- Select == and choose not in for the operator.
- Enter 10.0.0.0/8 in the Select Value field. This will filter out any IP addresses not in that range.
- Create a second filter for the 172.16.0.0/12 IP addresses. Select the filtered results from the previous block for the parameter.
- Create a third filter for the 192.168.0.0/16 IP addresses. Select the filtered results from the previous block for the parameter.
- Create the
geolocate ip
action block using the filtered results from the last filter block in the chain.
If a filter block eliminates all variables while filtering, the downstream action can't run.
Example of using a custom list in a filter
You can use custom lists in your Filter blocks to simplify checking against a fixed set of items. For example, instead of checking the source country of an IP address to see if it is North Korea, you can define a list of countries in a custom list, then check the IP address against all of the countries in the list. You can maintain custom lists using the web interface, REST API, and playbook API. See Create custom lists for use in playbooks in Use . The following image shows the classic playbook editor in .
In this example, use a custom list named Banned Countries in a filter by performing the following tasks:
- Configure a
geolocate ip
action in the playbook editor. - Drag the half-circle icon on the
geolocate ip
action block in the editor. - Select Filter from the list of block types.
- Select the Select Parameter field and select geolocate_ip_1.
- Select geolocate_ip_1:action_result_data.*.country_name.
- Use "in" or "not in" as the operator.
- Select the Select value field and select custom_list:Banned_Countries.
The country name of the source IP address is checked against the countries defined in the Banned Countries custom list.
Add an Action block to a playbook using the classic playbook editor | Use decisions to send artifacts to a specific downstream action with the classic playbook editor |
This documentation applies to the following versions of Splunk® SOAR (On-premises): 5.1.0, 5.2.1, 5.3.1, 5.3.2, 5.3.3, 5.3.4, 5.3.5, 5.3.6, 5.4.0, 5.5.0, 6.0.0, 6.0.1, 6.0.2, 6.1.0, 6.1.1, 6.2.0, 6.2.1, 6.2.2, 6.3.0, 6.3.1
Feedback submitted, thanks!